DUST Search - Dragonfly scout broken again...

REDBACK96USMC wrote:

Kristoff Atruin wrote:

My guess is that either the scripts to fix these problems weren't checked in or the changes weren't made to the master copy of the database backup, depending on how they're doing deployments. Then a developer goes to change something else and runs the script to recreate all the stat tables or restores the updated backup file like he's supposed to, but it didn't include the last round of changes.

Every new project I've been on in the last 6 years has had problems with this kind of issue, and every time I've gone on a personal crusade to get other developers to stop making cowboy fixes and start following a process that makes this kind of situation impossible. But it's a change to how they work and a little bit of work up fr. ont that seems unnecessary until you've blown up an app in production and can't roll back to the previous state easily, so they almost always resist.

Well I would consider a better class of programmers to work with. :-p I can recount horror story after story of people and projects like this. It is obvious CCP needs a good lead and firm processes. Proof is in the pudding.


Author	Thread Statistics \| Show CCP posts - 0 post(s)
Kristoff Atruin Subdreddit Test Alliance Please Ignore 2089	Posted - 2014.04.16 12:59:00 - [1] - Quote My guess is that either the scripts to fix these problems weren't checked in or the changes weren't made to the master copy of the database backup, depending on how they're doing deployments. Then a developer goes to change something else and runs the script to recreate all the stat tables or restores the updated backup file like he's supposed to, but it didn't include the last round of changes. Every new project I've been on in the last 6 years has had problems with this kind of issue, and every time I've gone on a personal crusade to get other developers to stop making cowboy fixes and start following a process that makes this kind of situation impossible. But it's a change to how they work and a little bit of work up front that seems unnecessary until you've blown up an app in production and can't roll back to the previous state easily, so they almost always resist.
Kristoff Atruin Subdreddit Test Alliance Please Ignore 2091	Posted - 2014.04.16 14:19:00 - [2] - Quote REDBACK96USMC wrote: Kristoff Atruin wrote: My guess is that either the scripts to fix these problems weren't checked in or the changes weren't made to the master copy of the database backup, depending on how they're doing deployments. Then a developer goes to change something else and runs the script to recreate all the stat tables or restores the updated backup file like he's supposed to, but it didn't include the last round of changes. Every new project I've been on in the last 6 years has had problems with this kind of issue, and every time I've gone on a personal crusade to get other developers to stop making cowboy fixes and start following a process that makes this kind of situation impossible. But it's a change to how they work and a little bit of work up fr. ont that seems unnecessary until you've blown up an app in production and can't roll back to the previous state easily, so they almost always resist. Well I would consider a better class of programmers to work with. :-p I can recount horror story after story of people and projects like this. It is obvious CCP needs a good lead and firm processes. Proof is in the pudding. Hah, well it isn't like I have much of a choice...the industry is packed with developers like this. I work for a consulting firm so I get to see inside a lot of different places and it's all the same everywhere. Once I had this app that our company had built from the ground up for a government department, and after years of maintenance and upgrades was being handed off to a new team. I literally spent hours trying to convince them of the value of source control combined with a build server. Hours! They didn't even have to set anything up, the servers and configs were already in place...all they had to do was keep following the process of adding a folder for the current build number, creating db change scripts and then grabbing the deployment zip file from the dev server. It was a process we had put in place so that a non-developer could do the actual deployment and, if something got mucked up, we could revert the whole thing in 10 minutes by grabbing a previous deployment zip and giving it to the dba or support monkey who was working at the time. Supposedly despite the fact that I've barely written more than a dozen lines of actual code in almost two years, understanding this makes me a "good" developer heh.